The present invention relates generally to cryptographic signing of electronic documents, and in particular to using a smart card to sign a document for a user in response to a request to have the document signed for the user by a network signing service.
OASIS Digital Signature Service (DSS) is an OASIS standard that describes how a digital signature service can be provided. The DSS Specification (“Digital Signature Service Core Protocols, Elements, and Bindings,” version 1.0, OASIS standard, Apr. 11, 2007.) details the digital signature service core protocols, elements, and bindings. The DSS Specification says:
“This (DSS) specification describes two XML-based request/response protocols—a signing protocol and a verifying protocol. Through these protocols a client can send documents (or document hashes) to a server and receive back a signature on the documents; or send documents (or document hashes) and a signature to a server, and receive back an answer on whether the signature verifies the documents.”
Different applications, i.e., different relying parties, may have different requirements for signing and verifying signatures. DSS handles this requirement through different DSS profiles, such as abstract code-signing profile, XML time-stamping profile, German signature law profile, and so on. The DSS provides a centralized service model so that applications can ask for signature services from a DSS server instead of having to deal with signature-related complexities themselves.
Digital signing is a cryptographic operation that uses the private key of a {public key, private key} pair. The private key belongs to its owner, must be securely stored, and should not be given to anyone else. In OASIS DSS, DSS manages or accesses private keys (also called signing keys), eliminating the need of distributing user keys and/or signing devices/software. The DSS model works well for signatures on an organization's behalf, such as code signing, business agreements, press release, and so on.
Using OASIS DSS, how the digital signature is created is not relevant to a relying party (RP). The OASIS DSS model works as long as the DSS server can access users' private keys. However, if the private keys are in users' smart cards, the keys are not directly accessible by the DSS server and the model breaks down
Some signature requirements conflict with the DSS model of storing the private keys on a central server; for example, certain European countries require that the private key stays with the user. Furthermore, for the centralized model, the security of the digital signing depends on the strength of the user authentication. Most of the authentication systems use usernames and passwords, one of the weakest forms of authentication. If a user's username and password are compromised, the attacker can sign documents without the user's knowledge, which could result in personal or organizational damage.
For individual signatures, the DSS model of centralized key management is less attractive. Many corporations, government agencies, and others have deployed the smart card infrastructure to use smart cards to secure private information associated with an individual user to allow for logical and physical access and to store individual secure information, e.g., the private keys. Each user within the organization has a smart card with private and public key pairs stored in it.
Often, these organizations require users to digitally sign documents, such as emails, using their smart cards. In this situation, the smart card works with the host application, for example Microsoft's email software, Outlook. The host application communicates with the smart card and asks the card to perform the digital signing operation through some middleware running on the host computer. The smart card carries the user's private key. It requires user authentication before performing any operations that involve the private key. This provides a two-factor security protection (what-you-know and what-you-have), which mitigates the risk mentioned above: the private key stays with the user; a compromised pair of username and password does not lead to a forged digital signature. However, there is no standard way of using smart cards to sign documents from web applications. Furthermore, each web application or RP that requires a user to digitally sign using a smart card must know how to communicate with the card.
Thus, DSS and smart card enabled digital signature mechanisms have certain advantages and disadvantages. It would be desirable to combine the advantages while overcoming the disadvantages to provide smart-card-based digital signatures to Web applications through a mechanism similar to DSS or as an enhancement to DSS.
From the foregoing it will be apparent that there is still a need for an improved method to provide a secure mechanism under which a portable security device, e.g., a smart card, connected to a host computer and having the capability of providing cryptographic signing services may cryptographically sign electronic documents on behalf of a user.